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(54) Network server for local and remote resources 

(57) A network server (14) permits clients (11) on 
the network to access one or more local resources man- 
aged by the network server and one or more remote 
resources managed by one or more respective remote 
computers coupled to the network server. When a client 
desires to access any of the resources, the client first 
requests a session or log-on to the network server by 
supplying a valid account name and password. Either 
with the session establishment request or subsequently 
during the same session, the client requests a connec- 
tion or access to a resource. The client need not know 
the location of the resource or the computer (remote or 
network server) which manages the resource. The net- 
work server determines which computer manages the 
requested resource. If the network server manages the 
resource, then the network server determines if the con- 
nection is available or provides the access as requested 
and responds to the client. Then, if the client subse- 
quently requests a connection with or access to a 
resource managed by a remote computer, or if the orig- 
inal request was for a resource managed by the remote 
computer, the network server sends a session estab- 
lishment request and connect or access request to the 
remote computer. The client need not send a separate 
session establishment request for the remote computer. 
If the remote computer grants the session, then the cli- 
ent can access the resource managed by the remote 
computer. 
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Description 

[0001] The invention relates generally to computer 
networks, and deals more particularly with a network 
server that permits a network client to access a local 
resource coupled directly to the network server and a 
remote resource coupled to a host computer 
[0002] A previously known local area network (LAN) 
is used to interconnect multiple personal computers or 
work stations, called "clients", and a network server. The 
network server comprises a personal computer and a 
program which provides a variety of services to the cli- 
ents. For example, the server manages a local disk 
(DASD) and permits selected (or all) clients on the LAN 
to access the disk. Also, the server may provide access 
by LAN clients to a local printer that the server manages. 
To access the local disk, the client must first establish a 
session or "log-on" to the server with a valid account 
and password and request a connection to the local 
disk. In response, the server validates the account and 
password, and grants the connection if available. Then, 
the client requests a remote file operation (e.g. open, 
read, write, close) and furnishes associated parame- 
ters. In response, the server may copy (depending on 
the operation) the file from the local disk into RAM, and 
performs the operation requested by the client, if the file 
is updated, the server will copy the updated version back 
to the local disk, overwriting the previous version. 
[0003] A previously known IBM LANRES/VM compu- 
ter system comprises a LAN, a network server and a 
remote disk driver (with a remote disk) coupled to the 
network server. The remote disk driver is in the form of 
a System/370 host computer; however, the System/370 
computer is not used as a computer for service to the 
network server, but merely as a disk driver for the remote 
disk. The network server maintains a list of all resources 
that the network server can access, i.e. the local disk, 
the remote disk, all directories on the local disk and all 
directories on the remote disk, and a table or pointers 
to map each directory and file within the directory to the 
storage location on the corresponding disk. The clients 
do not know where the requested resource resides. To 
access any of the resources, a client on the LAN must 
establish a session with or tog-on to the network server 
with a valid account and password, request a connec- 
tion to a named resource and provide a remote file op- 
eration/command and associated parameters. In re- 
sponse, the network server validates the account and 
password, determines the location of the named re- 
source and then translates the directory name into spe- 
cific addresses on the disk. If the file is located on the 
local disk, then the network server fetches the directory 
from the addresses and then performs the operation re- 
quested by the client. (The client may subsequently re- 
quest access to a file within the directory.) If the file is 
located on the remote disk, then the server provides to 
the remote disk driver the specific addresses of the di- 
rectory on the remote disk to be written to or read from 


and the write or read command. It should be noted that 
the network server cannot address the remote disk by 
a directory (or file) name, and the disk driver does not 
provide the security associated with a log-on require- 

s ment. Also, because the data cannot be accessed by a 
directory (or file) name or as any discernible entity, it is 
not possible for another application program which ex- 
ecutes on the System/370 computer to access the di- 
rectory or file; this other application program does not 

10 know the location of the directory or file. Nevertheless, 
there is an important advantage to this LANRES/VM 
computer system. As noted above, the client need not 
know the actual location of the disk; the disk can be local 
to the network server or connected to the remote disk 

f5 driver. In this respect, the server is "transparent" to the 
client. 

[0004] In .Marshall, A.D.,et al.: ,On the Feasibility Of 
ISO FTAM-Based File Servers To Implement A Heter- 
ogenous File System 1 , Computer Standards And Inter- 
na faces, vol. 14, no. 3, 1 Jan 1992, pages 191-208', a log- 
ical network model is described which has in each node 
a directory server responsible for providing directory 
services', i.e. for locating a remote ressource, as e.g., a 
searched file. 

2$ [0005] This yields to repeated requests to a plurality 
of node directory servers, if the requested file is not 
found at the first node requested. This is not an efficient 
way to search a particular file as, statistically, a number 
of remote hosts are requested which cannot contribute 
30 to locate the searched file or network resource. 

[0006] In WO 91/02305 a method to access remote 
applications - not in the sense of ressources in general 
sense as e.g., files in the present application • is de- 
scribed in which user identification or authentication 
35 does not play any relevant role when accessing said re- 
mote applications. 

[0007] Further, there is not provided any means for 
providing increased efficency of several subsequent ac- 
cesses to remote ressources, as e.g., files, because 
40 there is no need to authenticate the user and thus to 
hold such user information or session information in a 
central form on a network server. 
[0008] A general object of the present invention is to 
provide a network server which permits a client on a net- 
45 work to access more efficiently a local resource man- 
aged by the network server and a remote resource man- 
aged by a host computer, which host computer provides 
host computer services relating to the remote resource. 
[0009] Another object of the present invention is to 
so provide a network server of the foregoing type which 
permits a client to access both a local resource and a 
remote resource without knowing the location of either. 
[0010] Still another object of the present invention is 
to provide a network server of the foregoing type which 
55 permits an application program executing on the host 
computer to access the same directories and files on 
the remote resource that the clients can access. 
[0011] A more specific object of the present invention 
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is to provide a network server of the foregoing type in 
which the host computer provides security for the re- 
mote resource. 

[0012] Another specific object of the present invention 
is to provide a network server of the foregoing type 
which permits a client to access remote resources man- 
aged by different host computers, and to do so efficient- 
ly- 

[0013] These and other objects are solved advanta- 
geously by the invention as claimed. 
[0014] The invention resides in a network server that 
permits clients on the network to access one or more 
local resources managed by the network server and one 
or more remote resources managed by one or more re- 
spective remote computers coupled to the network serv- 
er. 

[0015] When a client desires to access any of the re- 
sources, the client first requests a session or log-on to 
the network server by supplying an account name and/ 
or password. If the account name and/or password are 
valid, the network server establishes a session with the 
client. Either with the session establishment request or 
subsequently during the same session, the client re- 
quests a connection or access to a resource. The client 
need not know the location of the resource or the com- 
puter (remote or network server) which manages the re- 
source, and does not specify the location in the request. 
The network server determines which computer man- 
ages the requested resource. If the network server man- 
ages the resource, then the network server determines 
if the connection is available or provides the access as 
requested and responds to the client. Then, if the client 
subsequently requests a connection with or access to a 
resource managed by a remote computer, or if the orig- 
inal request was for a resource managed by the remote 
computer, the network server sends a session estab- 
lishment request and connect or access request to the 
remote computer. The client need not send a separate 
session establishment request for the remote computer 
The remote computer then accepts or rejects the ses- 
sion establishment request based on security informa- 
tion stored in the remote computer for this client. If the 
session with the remote computer is established, then 
the client can access the resource managed by the re- 
mote computer. For efficiency, the other remote comput- 
ers are not informed of the session or otherwise inter- 
rupted. 

[0016] According to one feature of the present inven- 
tion, an application program executing on the host com- 
puter can also access the same remote resource man- 
aged by the host computer that the clients can access. 
[0017] The invention will be described in more detail 
by the following description in connection with embodi- 
ments shown in the drawing in which: 

Fig. 1 is a block diagram of a network server accord- 
ing to the present invention, a local DASD, a net- 
work of clients which can access the local DASD 


via the network server, and remote computers cou- 
pled to the network server. Fig. 1 also illustrates re- 
mote DASDs which are managed by the remote 
computers and which the clients can access via the 
s network server. 

Figs. 2(a) and 2(b) are flow charts illustrating gen- 
eral operation of a back end service program within 
the network server of Fig. 1 . 

Figs. 3(a-d) form a flow chart illustrating examples 
of operation of the network server and host comput- 
ers of Fig. 1 in response to specific requests by the 
clients. 

Figs. 4(a) and 4(b) form a flow chart illustrating other 
examples of operation of the network server and 
host computers of Fig. 1 in response to other spe- 
cific requests by the clients. 

Figs. 5(a) and 5(b) form a flow chart illustrating still 
other examples of operation of the network server 
and host computers of Fig. 1 in response to still oth- 
er specific requests by the clients. 

Fig. 6 is a block diagram illustrating a PCA adapter 
card within the network server of Fig. 1 . 

Detailed Description of Embodiments 

[001 8] Referring now to the drawings in detail wherein 
like reference numerals indicate like elements through- 
out the several views, Fig. 1 illustrates a computer net- 
work generally designated 10 which includes many pre- 
viously known clients 11a-z coupled together by a pre- 
viously known communication link 12 to form a LAN 1 3, 
and a network server 1 4 according to the present inven- 
tion. By way of example, each of the clients comprises 
a personal computer or a workstation which executes a 
DOS Lan Requestor, OS/2 LAN Requestor, PC LAN 
Program or LAN MAN For DOS client program, and a 
Token-Ring or Ethernet adapter card to interface the 
personal computer or workstation to the other clients 
and the network server via the communication link. The 
network server 14 comprises a previously known per- 
sonal computer such as an IBM PS/2 personal computer 
with a processor 18 (although the network server could 
also execute in a multiprocessor environment), an OS/ 
2 operating system 20, a DASD controller 22 for local 
DASD 24, and a Token-Ring or Ethernet adapter card. 
For further details of the PS/2 computer, reference can 
be made to the following document which is available 
from International Business Machines Corp. in Mechan- 
icsburg, Pennsylvania: "IBM PS/2 Reference Guide', 
G360-2669. The network server 14 also comprises a 
previously known parallel channel adapter (PCA) card 
28 to permit the network server to communicate with a 
host computer 30 via an associated channel 32, and 
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with a host computer 34 via an associated channel 36. 
By way of example, each of the host computers com- 
prises a previously known IBM System/370 or System/ 
390 computer and each of the channels comprises an 
IBM Block Multiplexor channel. The host computers 30 
and 34 provide basic computer functions such as secu- 
rity and management of respective DASDs 40 and 44. 
For further details of the host computers 30 and 34 and 
channels 32 and 36, reference can be made to the fol- 
lowing documents which are available from Internation- 
al Business Machines Corp. in Mechanicsburg, Penn- 
sylvania: " System/370 Principles of Operation" publica- 
tion number GA22-7000, and "ESA/390 Principles of 
Operation" publication number SA22-7201. 
[0019] Figs. 2(a) and (b) illustrate operation of net- 
work server 1 4 according to the present invention to per- 
mit any of the clients 11a-z to access the local DASD 
24, remote DASD 40 and remote DASD 44, When a cli- 
ent 1 1 a-z is initiated or subsequently when the client de- 
sires to access a directory or file on local DASD 24, re- 
mote DASD 40 or remote DASD 42, the client requests 
a session with or log-on to the network server 14. This 
request involves registration and authentication of an 
account name for the client, and requires a valid account 
name, password and other parameters as follows: 
Client Maximum Buffer Size 
Actual Maximum Multiplexed Pending Requests 
Virtual Circuit Number - when a client establishes a com- 
munications link with a network server, that link is given 
a number to identify it uniquely. This is that number. 
Session Key 

Account Password Length Account Password 
Account Name 

Consumer Maximum Buffer Size 
[0020] At the time of making the session establish- 
ment request or subsequently, the client may request a 
connection to a resource such as a directory by name. 
However, the client could have requested a connection 
to other types of resources, for example, an entire data 
repository such as one of the DASDs, a pan: of a data 
repository such as a minidisk, a printer (not shown), or 
another data entity such as a file. The connect request 
is a request to determine if the resource is available and 
if the requestor is authorized to access the resource. 
The client need not know the location of the resource or 
which computer 14, 30 or 34 manages the resource. The 
connect request usually precedes another command to 
actually read from or write to the resource. By way of 
example, all requests from the clients use a server mes- 
sage block (SMB) or Network File System (NFS) Re- 
mote Procedure Call (RPC) protocol, which are further 
defined in documents entitled "Microsoft Networks/ 
OpenNET File Sharing Protocol", Intel Part Number 
138446 Version 1.9, 04/21/87, Microsoft Corporation, 
Intel Corporation; "Microsoft Networks SMB FILE 
SHARING PROTOCOL EXTENSIONS: SMB File Shar- 
ing Protocol Extensions Version 2.0", Document Version 
3.2, 07/13/88. Microsoft Corporation; and "Microsoft 


6 

Networks SMB FILE SHARING PROTOCOL EXTEN- 
SIONS: SMB File Sharing Protocol Extensions Version 
3.0", Document Version 1.09, 11/29/89, Microsoft Cor- 
poration for SMB Protocol, and Internet RFC 1057, Sun 
5 Microsystems, Inc., June 1988 for NFS Protocol. 

[0021] A network interface 52 within network server 
14 receives the request(s), associates the request with 
the appropriate client and session, determines the cor- 
rect process to receive the request, and then passes the 
10 request(s) to a front end service program 53. The front 
end service program passes this request(s) (and all cli- 
ent requests), without change, to a back end service 
program 60. (The front end service program and back 
end service program are both executed by processor 1 8 
is after being loaded or read from a magnetic disk or tape 
into RAM 103). When the back end service program re- 
ceives the request (step 104), the back end service pro- 
gram determines if the request includes a session es- 
tablishment request (decision block 106). If so, the back 
20 end service stores in a session establishment data table 
54 the foregoing information from the client request and 
the following information which the front end service and 
the back end service generate (step 110): 


[0022] Session Structure Pointer • when a client ses- 
sion 

establishment requests is received by a network server, 
30 the network server associates this request with a control 
block of information about that client. This field is the 
address of that control block. Once the session is es- 
tablished, the network server sets a bit to indicate that 
this session is active. 
55 Session Encryption Key Length 
Session Encryption Key 

Remote Client Name Length - the length of the remote 
client name. 

Remote Client Name - this is the address of a block of 
40 storage that contains the machine name of the client that 
has/is attempting to establish a session with this net- 
work server. This address comes from the session struc- 
ture. 


[0023] Account Name Length 
Session Next Pointer - next instance of this structure 
based on session structure pointer • linked list. 
Session Previous Pointer 

Structure Next Pointer - next instance of this structure 
for any session - linked list. 
Structure Previous Pointer 
Structure Flags 

[0024] This information forms a client control block. 
[0025] Next, the back end service determines if the 
request includes a connect request, and if so, is the re- 
source for which connection is requested stored within 
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a remote DASD (or other external device) managed by 
either host computer 30 or 34 (decision block 112). The 
latter determination is made by reading a resource table 
56 to identity the location of the DASD or other external 
device that stores the file. If there is no such request to 
connect to resource managed by either remote DASD 
40 or 44, then the back end service returns the client 
request to the front end service for processing. The front 
end service then determines if the account and pass- 
word are valid by comparing them to lists of valid ac- 
counts and passwords, respectively. If the account and 
password are valid, the front end service establishes a 
session with the client by setting a flag in the session 
structure pointer field in the control blocks. Then the 
front end service notes the existence of the session in 
an active session table 57 and returns a session estab- 
lishment acknowledgement to the client via the network 
interface and to the back end service (step 116). If the 
request also includes a connect request for a resource 
managed by the network server such as a directory 
stored in local DASD 24, then the front end service also 
checks the status of the connection, and reports the out- 
come to the client. If the password is not valid, or if the 
session cannot be established for some other reason 
(such as a limit on the number of sessions allocated to 
each resource), then the front end service returns a ses- 
sion refusal message to the client (step 116). 
[0026] Referring again to decision block 1 1 2, if the cli- 
ent request includes a request to connect to a resource 
managed by remote computer 30 or remote computer 
34 such as remote DASD 40 or remote DASD 44, re- 
spectively, then the back end service passes the ses- 
sion establishment request to the front end service (step 
1 20), and waits for a return acknowledging session es- 
tablishment with the network server (step 1 22). The front 
end service then determines if the session can be es- 
tablished (i.e. valid account and password, no other 
problems), and sends the response to the back end 
service. If the session is not successfully established 
(decision block 123), then the back end service sends 
an error message to the client via the front end service, 
refusing the session (step 1 24). However, if the session 
is successfully established, then the back end service 
sends the entire client request including the session es- 
tablishment request and the connect request to the one . 
host computer which manages the resource for which 
connection is requested (step 130), and waits for a re- 
sponse (step 132). It should be noted that the form of 
the session establishment request and connect request 
sent to the host computer by the network server in step 
1 30 can be the same as that sent to the network server 
by the client. However, it may be necessary to provide 
a mapping between user/client ID, resource connection 
I D and file I D between that provided by the network serv- 
er and that required by the remote computer. When the 
response is received from the host computer indicating 
whether the session was established and the connec- 
tion is available, the back end service stores an identifier 


for this host computer in the client control block (step 
133), and passes the response to the front end service 
(step 134), then the front end service passes the re- 
sponse to the client via the network interface 52. The 
s form of the session establishment response originating 
from the host computer and sent to the client after step 
1 34 can be the same as that sent to the client after step 
116 when there was no connect request to either host 
computer. If it is not identical, the network server alters 
the format suitably. Consequently, the client does not 
know the origin of the session establishment response 
or connect response, and assumes that the client now 
has access to any resource available from the network 
server. To support this assumption, the network server, 
as described below, will subsequently request session 
establishment on behalf of the client with any other re- 
mote computer connected to the network server when 
and if the client requests access to a resource managed 
by this other remote computer. The client need not re- 
quest session establishment again during the course of 
the session that was just established after steps 1 20 and 
130. This makes the network server transparent to the 
clients, yet there is no burden ever (for session estab- 
lishment) on any host computer that does not manage 
a resource for which the client requests a connection. 
[0027] Subsequently, the client sends a request to the 
network server to access a named resource (assume 
the one for which a connect request was previously 
sent). The client need not know the location of the re- 
source or computer which manages the resource, and 
does not specify the location in the request. The front 
end service receives the request via the network inter- 
face, and passes the request to the back end service 
(step 104). Because this request is a resource access 
request and not a session establishment request (deci- 
sion block 106), the back end service next determines 
if the named resource is managed by either remote com- 
puter 30 or 34 (decision block 140). This determination 
is made by reading the resource table 56. If the named 
resource is instead managed by network server 14 (for 
example, stored on local DASD 24), then the back end 
service passes the request to the front end service for 
processing (step 116). For a read request, the front end 
service reads the directory from local DASD 24 into data 
buffer 69, and then sends the directory to the client for 
storage in the client's RAM. For a write request, the front 
end service writes the data supplied with the write com- 
mand into data buffer 60 and then into the directory with- 
in local DASD 24. Other types of requests are handled 
in an appropriate manner. 

[0028] Referring again to decision block 140, if the 
named resource is managed by either remote computer 
30 or 34 (for example, stored on either remote DASD 
40 or remote DASD 44), the back end service deter- 
mines that a session was previously established and is 
currently active for this client with the host computer that 
manages the requested resource (decision block 142). 
This determination is made by reading the active ses- 
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sion table 57. Then, the back end service sends the re- 
source access request to the host computer (step 130) 
and then waits for a response (step 1 32). If the resource 
access request is a read request, then the host compu- 
ter will read the resource from the remote DASD into 
host RAM, and send the resource to the data buffer 60, 
and the back end service will send the data to the client 
via the front end service (step 1 34). If the resource ac- 
cess request is a write request, the host computer will 
write the data into the remote DASD, and respond to the 
client via the front end service with an acknowledgement 
in step 1 34. 

[0029] The client can also send a request to connect 
to another resource which is managed by the (or any) 
other host computer. 

[0030] Referring again to decision block 142, if there 
is not yet a session established with this other host com- 
puter that manages the requested resource, then the 
back end service determines if session establishment 
data has been saved for this client by reading the ses- 
sion establishment data table 54 (decision block 148). 
If not, (which means that there is not an active session 
with the network server), then the back end service re- 
sponds to the client via the front end service with an error 
signal and refuses connection to the host computer 
(step 124). (The client can now request a session es- 
tablishment, and the flow chart of Fig. 2 will proceed as 
described above for steps 104, 106, 110 etc.) 
[0031] Referring again to decision block 148, if the 
session establishment data has been saved for this cli- 
ent (meaning that there is currently an active session 
with at least the network server), the back end service 
builds a session establishment request based on the 
session establishment data stored in the table 54 and 
sends the request to this other host computer (step 1 52). 
It should be noted that in accordance with an object of 
the present invention, the client itself is not burdened 
with establishing a session with the host computer or 
even knowing that a host computer manages the re- 
quested resource. It should also be noted that the back 
end service establishes sessions only with those host 
computer(s) that manage resources for which connec- 
tion or access has been requested, and the other host 
computer(s) are not interrupted. This maximizes effi- 
ciency. 

[0032] After sending the session establishment re- 
quest, the back end service waits for a response (step 
156) from the host computer. The host computer will 
then determine if the session should be established 
based on the account name, password and other infor- 
mation, and respond with a session establishment ac- 
knowledgement or refusal to the back end service. If the 
session with this client has been established (decision 
block 170), then the back end service will send the re- 
source connection to the host computer (step 1 30), and 
then execute steps 132, 133 and 134 as described 
above. The client can then follow with a resource access 
request. Referring again to decision block 170, if the 


host computer refuses to establish the session, then the 
back end service will pass the error message and refus- 
al to the client via the front end service (step 124). 
[0033] Fig. 2()b illustrates another portion of the back 

5 end service program which handles requests to termi- 
nate sessions. The requests can originate from either a 
client 1 1 a-z or be initiated by administrative action on 
the network server (or indirectly by administrative action 
from the remote computer(s)), and includes a session 

10 structure pointer parameter. 

[0034] The front end service receives this request, 
passes this request to an entry point in the back end 
service program corresponding to step 200, and proc- 
esses the deleted session with the client by ending all 

*5 work in progress by that client, and performing any 
needed cleanup. Then, the back end service reads the 
session establishment data table 54 to determine which 
of the network server, host computer 30 and host com- 
puter 34 have established a session with the requesting 

20 client (step 202). If neither of the host computers 30 nor 
34 (nor any other host computer) has established a ses- 
sion with the requesting client (decision block 204), then 
the back end service returns control to the front end 
service (step 206), which terminates its processing of 

25 this request. However, if either of the host computers 30 
or 34 has established a session with the requesting cli- 
ent, then the back end service builds a session delete 
notification (step 208) and sends the notification to all 
host computers that have established a session with the 

30 requesting client (step 210). The session delete notifi- 
cation includes the host identifier parameter that was 
stored in step 1 33. 

[0035] The notified host computers proceed to delete 
the session by ending all work associated with the user 

35 and performing any needed cleanup, and then return ac- 
knowledgements to the back end service which is wait- 
ing (step 212). Then, the back end service returns con- 
trol to the front end service, which terminates its 
processing of this request. 

40 [0036] Figs. 3(a-d) illustrate operation of the network 
server 14 (including the back end service described 
above) and associated host computers 30 and 34 in re- 
sponding to five specific requests by one client 11a on 
network 1 3. In step 310, the client issues a bundled re- 

45 quest for session establishment and connection to a re- 
source such as a directory that happens to reside in local 
DASD 24. The front end service passes the request to 
the back end service (step 312), the back end service 
stores the establishment data in step 1 1 0 and sends the 

so request to the front end service in step 116. Then the 
front end service establishes the session, processes the 
connect request, and notifies the back end service and 
the client of the session (step 314). Because the re- 
source is not managed by either remote computer 30 or 

55 34, the back end service does not attempt to establish 
a session with either remote computer 30 or 34. 
[0037] In step 320, the client subsequently issues a 
connect request for a resource such as a directory that 
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happens to reside on remote DASD 40 which is man- 
aged by host computer 30. The front end service passes 
the request to the back end service (step 322), and the 
back end service performs steps 1 52 and 1 56 described 
above in which the back end service requests that a ses- 
sion be established with host computer 30 and then 
waits for the response. This is necessary because the 
resource resides on remote DASD 40, and the session 
established in step 314 was confined to the network 
server. The host computer establishes the session (step 
324), and then the back end service performs steps 1 30 
and 1 32 described above in which the back end service 
sends the connect request to the host computer and 
waits for the response. Then, the host computer proc- 
esses the connect request and responds to the back end 
service with the result (step 326). Then, the back end 
service sends the response to the client via the front end 
service (step 134). 

[0038] In step 330, the client subsequently issues a 
request to connect to a second resource that happens 
to reside also on remote DASD 40. The front end service 
passes the request to the back end service (step 332), 
and the back end service sends the connect request to 
the host computer 30 (step 1 30). Because there is al- 
ready a session established with host computer 30 for 
client 11a, it is not necessary to establish another ses- 
sion with host computer 30. Then the host computer 30 
processes the connect request (step 334), and then the 
back end service returns the response to the client via 
the front end service (steps 132 and 134). 
[0039] In step 340, the client subsequently issues a 
request to connect to a resource that happens to reside 
on the other remote DASD 44 which is managed by host 
computer 34. The front end service passes the request 
to the back end service (step 342), and the back end 
service executes steps 1 52 and 1 56 described above in 
which the back end service requests a session with host 
computer 34 for client 1 1 a and then waits for a response. 
Then the host computer 34 establishes the session with 
the client 11a and responds with an acknowledgement 
(step 344). Such a session is necessary because the 
resource resides on remote DASD 44, and the sessions 
established earlier in steps 31 3 and 324 did not involve 
host computer 34. Then, the back end service passes 
the connect request to the host computer 34 and waits 
for a response (steps 130 and 132), the host computer 
34 processes the request and returns a response (step 
346). In step 1 34, the back end service forwards the re- 
sponse to the client via the front end service. It should 
be noted that the session with host computer 34 was not 
established until the client requested a connection to 
DASD 44; this optimizes efficiency. 
[0040] In accordance with one object of the invention, 
an application program executing on the host computer 
30 can access the same remote resource such as a di- 
rectory on DASD 40 that the client can access. This is 
illustrated by step 348 in which a user application pro- 
gram 349 executing on host computer 30 (or coupled to 


the host computer 30 via a communication facility not 
shown) makes a request to the host processor to link 
the application program to a minidisk portion of DASD 
40. This linkage provides the application program with 
s access by resource name to all the resources on the 
minidisk including the directory that was accessed by 
the client. Thus, the application program can now read 
from or write to the directory and any file therein stored 
on the minidisk by open, read, write or delete, close and 
other commands, 

[0041] In step 350, the client subsequently issues a 
request to terminate the session. It should be noted that 
the client need not know that sessions were established 
also with host computers 30 and 34. The front end serv- 
ice passes the request to the back end service (step 
352), and the back end service executes steps 200-206 
described above in which the back end service deter- 
mines which host computers have an active session 
with this client, builds a session termination notification 
and sends it to each host computer which has an active 
session for this client. In this example, host computers 
30 and 34 currently have an active session with this cli- 
ent. Then, the host computers 30 and 34 terminate their 
sessions with this client 11a (steps 354 and 356). 
[0042] Figs. 4(a) and (b) illustrate operation of the net- 
work server 14 (including the back end service de- 
scribed above) and associated host computer 30 in re- 
sponding to three other specific requests by one client 
1 1 a on network 1 2. In step 41 0, client 1 1 b, issues a bun- 
dled request for session establishment and a connec- 
tion to a resource that happens to reside on DASD 40 
which is managed by host computer 30. The front end 
service passes the request to the back end service (step 
412), and the back end service saves the session es- 
tablishment data and returns control to the front end 
service (steps 110 and 120). Then the front end service 
establishes the session, transfers control to the back 
end service and notifies the back end service that the 
session has been established (step 414). Next, the back 
end service executes steps 122 and 130 described 
above in which the back end service requests a session 
with host computer 30 for client 1 1 b, and then host com- 
puter 30 establishes the session with client 11b, proc- 
esses the connect request, and returns the result of the 
connect request processing to the back end service 
(step 41 6). Then, the back end service returns the result 
to the client via the front end service (step 134). 
[0043] In step 420, the client 1 1 b issues a connect re- 
quest within the same session that was established in 
step 414 for a resource that happens to reside within 
local DASD 24. The front end service passes the re- 
quests to the back end service (step 422), and the back 
end service returns the request to the front end service 
because the request involves only local DASD 24 (step 
116 described above). Then, the front end service proc- 
esses the connect request (step 424). It is not necessary 
to establish any other sessions in view of the existing 
session with network server 14 for client 11b. 
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[0044] In step 430, the client 11b issues a request to 
terminate the session that was established in step 414, 
and the front end service passes the request to the back 
end service (step 432). Then, the back end service de- 
termines that a session currently exists for this client 
with host computer 30, builds a session termination no- 
tification based on the client request, and sends the no- 
tification to host computer 30 (steps 202, 208 and 210). 
It is not necessary to send the notification to host com- 
puter 34 because no session was previously estab- 
lished for client 11b on account of the requests made in 
Fig. 4 (a) and (b). In step 434, the host computer 30 
terminates the session with client 11b. 
[0045] Figs. 5(a) and (b) illustrate operation of the net- 
work server 14 (including the back end service de- 
scribed above) and associated host computers 30 and 
34 in responding to three other specific requests by one 
client 11c on network 12. In step 510, client 11c issues 
a session establishment request to network server. The 
front end service passes the request to the back end 
service (step 512), and the back end service saves the 
session establishment data and returns the request to 
the front end sen/ice (steps 1 1 0 and 1 1 6). Because there 
is no request to connect to a resource on either remote 
D ASD (or any resource), it is not necessary for the back 
end service to pass any request to either host computer 
30 or 34. In step 514, the front end service establishes 
the session with client 11c, notifies the back end service 
of the session establishment, and returns a session es- 
tablishment notification to the client 11c. 
[0046] In step 520, the client 11c sends a connect re- 
quest to the network server for a resource that happens 
to reside on DASD 44 which is managed by host com- 
puter 34. The front end service passes the request to 
the back end service (step 524), and the back end serv- 
ice builds a session establishment request based on the 
data stored in the session establishment data table, and 
sends the request to host computer 34 (steps 152 and 
1 56). In step 524, host computer 34 establishes the ses- 
sion with client 11c and returns an acknowledgement to 
the session establishment request. Because the con- 
nect request does not involve host computer 30, the cli- 
ent requests are not sent to host computer 30 and host 
computer 30 is not interrupted in any way. After receiv- 
ing the response from the host computer 34, the back 
end service passes the connect request to host compu- 
ter 34 and waits for a response (steps 130 and 132). 
The host computer 34 processes the connect request 
and returns a response (step 524). The back end service 
forwards the response to the client via the front end serv- 
ice (step 134). 

[0047] In step 530, the client 11c issues a request to 
the network server to terminate the session. The front 
end service passes the request to the back end service 
(step 532), and the back end service determines that 
host computer 30 has established a session with the cli- 
ent 11c, builds a session termination notification and 
sends it to the host computer 34. Because the host com- 


puter 30 was never involved with the client request of 
Fig. 5, the back end service does not send the session 
termination notification to host computer 30. 1 n step 534, 
the host computer 34 terminates the session with client 
5 11c. 

[0048] The following is a detailed description of the 
channels 32 and 36, and the PCA card 28, although the 
present invention does not depend on the specific type 
of communication facilities which are utilized. 

jo [0049] Each of the host computers 630 and 634 in- 
cludes a host processor 670 and 674, a main memory 
680 and 684, a "Blue" bus 690 and 694 servicing the 
host processor, the main memory, the Block Multiplexor 
channel 632 and 636, and DASD controllers 697 and 

is 699 respectfully. DASD controllers 697 and 699 control 
the reading from and writing to the remote DASD 640 
and 644 respectively, and are well known in the art. 
[0050] Each channel includes a host port, a buffer 
memory to temporarily store all data transferred be- 

20 tween the Blue bus and the host port, and a channel 
processor to control the data transfer from the main 
memory to the host port via the buffer memory. The 
channel relieves the host processor of the burden of 
transferring data between the main memory of the host 

25 computer and the host port, and once called by the host 
processor, is independent of the host processor. 
[0051] To initiate a data transfer from the main mem- 
ory to the host port, the host processor (under the direc- 
tion of a host control program) builds a channel program 

30 including a sequence of channel command words 
(CCWs), and stores a channel address word at a pre- 
determined location. The channel address word points 
to the first CCW in the channel program. Each CCW in- 
cludes a command such as read or write, a byte length 

35 indicating the length of data to be read or written, and a 
pointer to the first location in main memory to store the 
data to be read in the case of a read CCW, or the first 
location of the data to be written in the case of a write 
CCW. The, the host processor issues a Start I/O com- 

40 mand which addresses the target device, in this case, 
the channel. 

[0052] The channel processor receives the Start I/O 
command and fetches the first CCW. Pursuant to a sin- 
gle write CCW, the channel processor fetches a block 

45 of data from (host) main memory at a location indicated 
by the pointer and copies the data intothe channel buffer 
memory. Next, the channel processor dispatches anoth- 
er task which executes on the channel processor to be- 
gin the transfer to the PCA card of the block of data that 

50 was recently copied into the channel buffer memory. 
Then, the channel processor processes subsequent 
write CCWs, if any, by fetching the corresponding blocks 
of data from the main memory and copying the data into 
the channel buffer memory. 

55 [0053] The channel is corrected to the PCA card 628 
by an IBM Bus and Tag cable. The Bus and Tag cable 
includes many parallel coaxial conductors to transmit 
data, address and control signals in parallel. 
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[0054] As illustrated in Fig. 6, the PCA card includes 
an Intel 80C186 microprocessor ("PCA processor') 642 
and a shared RAM 44. The PCA processor 42 as well 
as the PS/2 processor 61 8 and channel state machine 
48 (within the PCA card) can all directly access shared 
RAM 44 (with permission by arbiter 50). Shared RAM 
44 includes a communication area for communication 
between the PS/2 processor 618 executing PCA driver 
code 630 and the PCA processor 642, and the transmit 
and receive data buffers to temporarily store all data 
transferred between a Micro Channel (R) bus associat- 
ed with the PS/2 processor and the channel, a multiplex- 
or 47 is located between shared RAM 44 and the Micro 
Channel (R) bus control logic 45 provides hand-shaking 
for the Micro Channel (R) bus and address latching for 
addresses supplied to the Micro Channel (R) bus. Chan- 
nel state machine 48 provides channel protocol and 
control sequences for communication with the channel. 
Arbiter 50 arbitrates access to shared RAM 44 between 
the Micro channel (R) bus, the channel state machine 
48, and the PCA processor 42. A program RAM 56 
stores PCA processor microcode, and channel status 
and device information, and forms a command FIFO 
and a status FIFO described below. 
[0055] Channel interface logic or remote port 57 in- 
cludes drivers and receivers for interfacing to channel 
bus and tag lines. Micro Channel (R) interface logic 41 
includes the multiplexer 47 and latches for interfacing to 
address and data tines on the Micro Channel (R) bus. 
[0056] The following procedure is used to transfer da- 
ta from the data buffer 669 of the PS/2 processor to the 
RAM 680 or 684 of the host processor with initiation from 
the PS/2 processor. First, the PS/2 processor obtains 
access to RAM 44 with permission from arbiter 50 in or- 
der to read a list in RAM 44 of available transmit data 
buffers. Neither the System/370 processor nor the chan- 
nel participates in the decision where to store the data 
in RAM 44. Then, the PS/2 processor writes the data 
into an available data buffer in RAM 44. Next, the PS/2 
processor sends a write command message with device 
address, buffer address and transfer size to the PCA 
processor 42 via the communication area in the shared 
RAM. The PCA processor processes the write com- 
mand by setting up control parameters, i.e. attention sta- 
tus, buffer address, and transfer size in the program 
RAM table. The PCA processor then writes the device 
address corresponding to the channel into the com- 
mand FIFO. The channel state machine 48 reads out 
the device address from the command FIFO and sends 
the attention status to the channel. The channel then 
interrogates the write command pending on the PCA 
card. Because of the channel protocol, the PCA will not 
send the data until a matching (read) command is re- 
ceived from the channel. 

[0057] The channel subsequently responds to the 
write command from the PS/2 processor with a read 
command. The channel state machine matches the 
channel read command with the PS/2 write command 
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and notifies the channel state machine of the match. 
Then, the channel state machine sets up the data buffer 
addresses and length count and controls the data trans- 
fer from the RAM 44 to the channel. Upon completion 
5 of the data transfer to the channel, the channel state 
machine writes an entry in the status FIFO to notify the 
PCA processor that the write operation has been com- 
pleted. 

[0058] The following procedure is used to transfer da- 

io ta from the data buffer 669 of the PS/2 processor to the 
RAM 680 or 684 of the host processor with initiation by 
the host processor. The host processor builds a channel 
program which includes a read CCW, and issues the 
Start I/O command to the channel. The channel fetches 

is the read CCW, and sends a read command to the PCA 
card. Assuming that data is not waiting in the PCA buffer 
for transmission to the channel, the channel state ma- 
chines 48 will return "command retry status" to notify the 
host processor that the data is not immediately availa- 

20 ble. After returning the command retry status, the chan- 
nel state machine 48 writes an entry in the status FIFO 
to notify the PCA processor of the read command re- 
ceived from the channel. In response, the PCA proces- 
sor notifies the PS/2 processor about the read com- 

2S mand. When the PS/2 processor has data to send to the 
host processor, the PS/2 identifies an available buffer in 
RAM 44, and writes the data into the available buffer. 
Then, the PS/2 processor writes a message into the 
shared communication area of RAM 44 to notify the PCA 

30 processor of the existence and location of the data. In 
response, the PCA processor makes an entry into the 
command FIFO to notify the channel state machine of 
the write command from the PS/2 processor and the tar- 
get device address. The channel state machine sends 

35 a "data ready" status signal to the channel, and the 
channel responds with the read command again. Final- 
ly, the channel state machine 48 controls the data trans- 
fer from the transmit buffer in RAM 44 to the channel 
buffer. 

40 [0059] The following procedure is used to transfer da- 
ta from the RAM 680 or 684 of the channel to the data 
buffer 669 of the PS/2 processor with initiation from the 
host processor. The host processor builds a channel 
program which includes a write CCW, and issues the 

45 start I/O to the channel. The channel fetches the write 
CCW and corresponding data from the main memory, 
and stores the data in the channel data buffer. Then, the 
channel sends to the PCA card a corresponding write 
command. The channel state machine 48 obtains a data 

so buffer from the shared RAM 44 by reading the list of 
available data buffers. (In the PCA system, it is not nec- 
essary to interrupt the PS/2 processor at this time.) Nei- 
ther the System/370 processor nor the channel partici- 
pates in the decision where to store the data in RAM 44. 

ss Then the channel state machine 48 controls the data 
transfer from the channel to the shared "RAM with the 
channel responding to control sequences established 
by the state machine 48. Upon completion, the channel 
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state machine writes an entry into the status FIFO to 
notify the PCA processor about the receipt of the data 
from the channel and the location and length of the data 
in he receive buffer in RAM 44. The PCA processor 
reads out the entry from the status FIFO and then noti- 
fies the PS/2 processor via the communication area in 
the shared RAM. The PS/2 processor finally moves the 
data from the shared RAM into the PS/2 system RAM. 
[0060] The PS/2 processor can also initiate transfer 
of data from RAM 680 or 684 of the host processor to 
the data buffer 669 of the PS/2 processor. First, the PS/ 
2 processor obtains access to RAM 44 (with permission 
from arbiter 50) in order to read the list of available re- 
ceive data buffers. Then, the PS/2 processor sends a 
read command message with device address, buffer ad- 
dress and transfer size to the PCA processor 42 via the 
communication area in the shared RAM. The PCA proc- 
essor processes the read command by setting up con- 
trol parameters, i.e. attention status, buffer address, and 
transfer size, in the program RAM table. The PCA proc- 
essor then writes the device address corresponding to 
the channel into the command FIFO. The channel state 
machine 48 reads out the device address from the chan- 
nel FIFO and sends the attention status to the channel. 
The channel then interrogates the read command pend- 
ing on the PCA card. The channel subsequently re- 
sponds to the read command with a write command. 
The channel state machine matches the channel write 
command with the PS/2 read command. Then, the 
channel state machine sets up the data buffer address- 
es and length count and control the data transfer from 
the channel to the RAM 44. Upon completion of the data 
transfer from the channel, the channel state machine 
writes an entry in the status FIFO to notify the PCA proc- 
essor that the read operation has been completed. 
[0061] Instead of using the PCA driver 630, PCA card 
28 and channels 32 and 36, the following commercially 
available software and hardware can be used to provide 
two alternate configurations. An IBM Personal Worksta- 
tion Communication Services/VM program can execute 
on the processor 18 to interface processor 18 and data 
buffer 69 to an IBM Token-Ring Network 16/4 Adapter/ 
A (IBM part number 74F9410) which is located at the 
network server. The Token-Ring Network 1 6/4 Adapter/ 
A is coupled to an IBM Integrated LAN adapter (IBM part 
number 61 34 for an ES/9000 type of host computer and 
part number 6034 for a 9370 type of host computer) 
which is located at the host computer and interfaces to 
the host processor. 

[0062] Alternately, the IBM VM Personal Workstation 
Communication Services (PWSCS) program executes 
on the processor 18 to interface processor 18 and data 
buffer 69 to an IBM Channel Emulator/A card (IBM part 
number 1674899) which is located at the network serv- 
er. AN IBM 3088 multisystem channel communication 
unit interconnects the Channel Emulator/A card to the 
Block Multiplexor channel of the host computer. Other 
connectivities are also available with PWSCS program. 


[0063] Based on the foregoing, a network server ac- 
cording to the present invention has been disclosed. 
However, numerous modifications and substitutions can 
be made without deviating from the scope of the present 

5 invention. For example, different type of networks, i.e. 
different clients and different network communication 
links, can be served by the network server, and the net- 
work server can interface to different types of remote 
computers. Also, the files can be stored on other types 

10 of repositories. Therefore, the invention has been dis- 
closed by way of illustration and not limitation, and ref- 
erence should be made to the following claims to deter- 
mine the scope of the present invention. 


1 . A method for managing access by clients (1 1 a- 1 1 z) 
in a network to one or more local resources (24) 
20 managed by a network server (14) and one or more 
remote resources (40,44) managed by one or more 
respective remote computers (30,34) logically and/ 
or physically coupled to the network server, said 
method comprising the steps of: 

25 

sending (310) from one of said clients to said 
network server a request to establish a session 
and a request to connect to or access a first 
resource (24), wherein said requests are pref- 
30 erably provided by a single request, said ses- 

sion establishment request including an ac- 
count name and password for said one client; 

in response to the session establishment re- 
35 quest (1 23), establishing by said network serv- 

er a session between said network server and 
said client, and storing (133) said account 
name and password; 

40 in response to the request to connect to or ac- 

cess said first resource, determining that said 
first resource is managed by said network serv- 
er, and determining if said connection is avail- 
able to said first resource (24); 

45 

subsequently, sending (310) from said one cli- 
ent to said network server a request to connect 
to or access a second resource (40,44); and 

50 in response to said subsequent request to con- 

nect to or access said second resource (40,44), 
determining (140) by said network server that 
one of said remote computers (30,34) manages 
said second resource, sending (152) a request 
55 by said network server to said one remote com- 

puter to establish a session with said one re- 
mote computer, said request including said 
stored account name and password, and send- 
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ing a request by said network server to said one 
remote computer to connect to or access said 
second named resource. 

2. Method as set forth in claim 1 further comprising the s 
subsequent steps of: 

sending (340) from said one client (11a-11z) to 
said network server (14) a request to connect 
to or access a third resource; '0 6. 

determining by said network server that anoth- 
er one of said remote computers manages said 
third resource; and 

sending (1 30) by said network server to said 
other remote computer a request to establish a 
session, said session establishment request in- 
cluding said stored account name and pass- 
word, and a request to connect to or access 
said third resource. 

3. Method as set forth in claim 1 or 2 further comprising 
the steps of: 

validating (324, 344) by said one remote com- 
puter said account name and password includ- 
ed in said session establishment request, and 

establishing (326,334, 341 ) by said one remote 30 
computer said session requested by said net- 
work server. 

4. Method as set forth in claim 3 further comprising the 
steps of: 35 

sending from said one client (11a-11z) to said 
network server (1 4) a request to terminate said 
session; 


5. 


determining (202,204) by said network server 
that said one remote computer is involved in 
said session; 

sending (352) by said network server to said 
one remote computer a request to terminate 
said session requested by said network server; 
and 

terminating (208) by said network server the 
session between said network server and said 
one client. 

Method as set forth in claim 1 or one of the claims 
2 to 4, further comprising the steps of: 

after said subsequent request, making a re- 
quest by another application program execut- 
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ing within said one remote computer to access 
said second resource (40,44); and 

pursuant to said application program request 
by said other application program, providing ac- 
cess by said one remote computer (30,34) to 
said other application program to said second 
resource. 

Method as set forth in claim 1 or one of the claims 
2 to 5, wherein the subsequent connect or access 
request sent (1 40) by said one client to said network 
server specifies said second resource by name, but 
does not specify said one remote computer or loca- 
tion of said second resource. 

A method for managing access by clients (11a-11z) 
in a network to a local resource (24) managed by a 
network server (14) and one or more remote re- 
sources (40,44) managed by one or more respec- 
tive remote computers (30,34) logically and/or 
physically coupled to the network server, said meth- 
od comprising the steps of: 

sending (31 0) from one of said clients to said 
network server a request to establish a session 
and a request to connect to or access a first 
resource (40,44), wherein said requests are 
preferably provided by a single request, said 
session establishment request including an ac- 
count name and a password for said one client; 

in response to the session establishment re- 
quest (123), establishing by said network serv- 
er a session with said network server, and stor- 
ing (1 33) said account name and password; 

in response to the connect or access request, 
determining that one of said remote computers 
manages (30,34) said first resource (40,44), 
sending (1 52) a request by said network server 
to said one remote computer to establish a ses- 
sion with said one remote computer, said re- 
quest including said stored account name and 
password, and sending a request by said net- 
work server to said remote computer to connect 
to or access said first resource; 

subsequently, sending (310) from said one cli- 
ent to said network server a request to connect 
to or access a second resource; and 

in response to said subsequent request, deter- 
mining (140) that said network server manages 
said second resource, and determining wheth- 
er said second resource is available. 


8. Method as set forth in claim 7 further comprising the 
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step of establishing said session with said one re- 
mote computer by said one remote computer vali- 
dating (324) said account name and password, in 
response to said session establishment request 
(1 52) from said network server. 5 

9. A network server (14) for managing access by cli- 
ents (1 1 a- 11 z) in a network to one or more local re- 
sources (24) managed by the network server and 
one or more remote resources (40,44) managed by io 
one or more respective remote computers (30,34) 
logically and/or physically coupled to the network 
server, said network server comprising: 

means (52) for receiving from one of said cli- is 
ents on said network a request to establish a 
session and a request to connect to or access 
a first resource, wherein said requests are pref- 
erably provided by a single request, the session 
establishment request including an account 20 
name and password for said one client; 

means (53,54) responsive to the session estab- 
lishment request, for establishing a session be- 
tween said network server and said one client, 25 
and storing said account name and password; 

means (56), responsive to the request to con- 
nect to or access said first resource, for deter- 
mining that said first resource is managed by 30 
said network server, and determining if said 
connection is available to said first resource; 
and 

means (56,60), responsive to a subsequent re- 35 
quest from said one client to connect to or ac- 
cess a second resource, for determining that 
one of said remote computers manages said 
second resource, sending a request to said one 
remote computer to establish a session with 40 
said one remote computer, said request includ- 
ing said stored account name and password, 
and sending a request to said one remote com- 
puter to connect to or access said second re- 
source. 45 

10. Network server as set forth in claim 9 wherein: 

the determining means (56) is responsive to an- 
other request from said one client to connect to 50 
or access a third resource to determine that an- 
other one of said remote computers manages 
said third resource; and 
the sending means (60) sends to said other re- 
mote computer a request to establish a ses- 55 
sion, said session establishment request in- 
cluding said stored account name and pass- 
word, and a request to connect to or access 


said third resource. 

11. Network server as set forth in claim 9 or 10 further 
comprising: 

means, responsive to a request from said one 
client to terminate said session, for determining 
that said one remote computer is involved in 
said session; 

means (60) for sending to said one remote 
computer a request to terminate said session 
requested by said network server; and 

means for terminating the session between 
said network server and said one client. 

12. Network server as set forth in claim 9, 10 or 11 
wherein the subsequent connect or access request 
sent by said one client to said network server spec- 
ifies said second resource by name, but does not 
specify said one remote computer or a location of 
the resource managed said one remote computer. 

13. A network server (14) for managing access by cli- 
ents (11a-11z) in a network to a local resource (24) 
managed by the network server and one or more 
remote resources (40,44) managed by one or more 
respective remote computers (30, 34) coupled to 
the network server, said network server comprising: 

means (52,53) for receiving from one of said 
clients on said network a request to establish a 
session and a request to connect to or access 
a first resource, the session establishment re- 
quest including an account name and a pass- 
word for said one client; 

means (54,60), responsive to the session es- 
tablishment request, for establishing a session 
with said network server, and storing said ac- 
count name and password; 

means (56), responsive to the connect or ac- 
cess request, for determining that one of said 
remote computers manages said first resource, 
sending a request to said one remote computer 
to establish a session with said one remote 
computer, said request including said stored 
account name and password, and sending a re- 
quest to said remote computer to connect to or 
access said first resource; and 

means (56), responsive to a subsequent re- 
quest to connect to or access a second re- 
source, for determining that said network serv- 
er manages said second resource, and deter- 
mining whether said second resource is avail- 
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able. 

14. A computer program product tor managing access 
by clients (1 1 a- 11 z) in a network to one or more local 
resources (24) managed by the network server (14) 
and one or more remote resources (40,44) man- 
aged by one or more respective remote computers 
(30,34) logically and/or physically coupled to the 
network server, said computer program product 
comprising: 

a computer readable medium; 

a first program instruction means, recorded on 
said medium, for instructing a computer proc- 
essor to receive from one of said client or said 
network a request to establish a session and a 
request to connect to or access a first resource, 
the session establishment request including an 
account name and password for said one client; 

second program instruction means, recorded 
on said medium, for instructing a computer 
processor to respond to the session establish- 
ment request by establishing a session be- 
tween said network server and said client, and 
storing said account name and password; 

third program instruction means, recorded on 
said medium, for instructing a computer proc- 
essor to respond to the request to connect to 
or access said first resource, by determining 
that said first resource is managed by said net- 
work server, and determining if said connection 
is available to said first resource; and 

fourth program instruction means, recorded on 
said medium, for instructing a computer proc- 
essor to respond to a subsequent request from 
said one client to connect to or access a second 
resource, by determining that one of said re- 
mote computers manages said second re- 
source, sending a request to said one remote 
computer to establish a session with said one 
remote computer, said request including said 
stored account name and password, and send- 
ing a request to said one remote computer to 
connect to or access said second resource; and 

wherein each of said program instruction 
means is executable by the associated compu- 
ter processor. 

15. Computer program product as set forth in claim 14 
wherein 

the third program instruction means is respon- 
sive to another request from said one client to 


connect to or access a third resource by in- 
structing a computer processor to determine 
that another one of said remote computers 
manages said third resource; and 

5 

the fourth program instruction means instructs 
a computer processor to send to said other re- 
mote computer a request to establish a ses- 
sion, said session establishment request in- 
io eluding said stored account name and pass- 

word, and a request to connect to or access 
said third resource. 

16. Computer program product as set forth in claim 14 
15 or 1 5 further comprising: 

fifth program instruction means, recorded on 
said medium, for instructing a computer proc- 
essor to respond to a request from said one cli- 
20 ent to terminate said session, to determine that 

said one remote computer is involved in said 
session; 

sixth program instruction means, recorded on 
25 said medium, for instructing a computer proc- 

essor to send to said one remote computer a 
request to terminate said session requested by 
said network server; and 

30 seventh program instruction means, recorded 

on said medium, for instructing a computer 
processor to terminate the session between 
said network server and said one client; and 
wherein said fifth, sixth and seventh program 

35 instruction means are executable by the asso- 

ciated computer processor. 

17. Computer program product as set forth in claim 1 4, 
1 5 or 1 6 wherein the subsequent connect or access 

40 request sent by said one client specifies said sec- 
ond resource by name, but does not specify said 
one remote computer or an address of the resource 
managed said one remote computer. 

45 18. A computer program product for managing access 
by clients in a network to a local resource managed 
by the network server and one or more remote re- 
sources managed by one or more respective re- 
mote computers coupled to the network server, said 

so computer program product comprising: 

first program instruction means, recorded on 
said medium, for instructing a computer proc- 
essor to receive from one of said clients on said 
55 network a request to establish a session and a 

request to connect to or access a first resource, 
the session establishment request including an 
account name and password for said one client; 
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second program instruction means, recorded 
on said medium, for instructing a computer 
processor to respond to the session establish- 
ment request by establishing a session with 
said network server, and storing said account 5 
name and password; 

third program instruction means, recorded on 
said medium, for instructing a computer proc- 
essor to respond to the connect or access re- 10 
quest by determining that one of said remote 
computers manages said first resource, send- 
ing a request to said one remote computer to 
establish a session with said one remote com- 
puter, said request including said stored ac- 75 
count name and password, and sending a re- 
quest to said remote computer to connect to or 
access said first resource; and 

fourth program instruction means, recorded on 20 
said medium, for instructing a computer proc- 
essor to respond to a subsequent request to 
connect to or access a second resource by de- 
termining that said network server manages 
said second resource, and determining wheth- 2s 
er said second resource is available; and 
wherein 

each of said program instruction means is ex- 
ecutable by the associated computer proces- so 
sor. 2. 

Patentanspruche 

35 

1 . Ein Verfahren zum Verwalten des Zugriffs durch Cli- 
ents (11 a-1 1 z) in einem Netzwerk auf ein oder meh- 
rere lokaie Betriebsmittel (24), die von einem Netz- 
werk-Server (14) verwaltet werden, und ein oder 
mehrere Fernbetriebsmittel (40, 44), die von einem 40 
oder mehreren entsprechenden Fernrechnern (30, 
34) verwaftet werden, logisch und/oder physika- 
lisch gekoppelt an den Netzwerk-Server, wobei das 
Verfahren die folgenden Schritte umfaBt: 

45 

Senden (310), von einem der Clients an den 
Netzwerk-Server, einer Anforderung zum Auf- 
bau einer Sitzung, und einer Anforderung zum 
Verbinden mit, oder Zugreifen auf, ein erstes 
Betriebsmittel (24), wobei diese Anforderungen 50 
vorzugsweise durch eine einzige Anforderung 
vorgesehen sind, und diese Sitzungsaufbau- 3. 
Anforderung einen Account-Namen und ein 
PaGwort fur den betreffenden Client enthalt; 

$5 

als Reaktion auf die Sitzungsaufbauanforde- 
rung (123) Aufbau einer Sitzung zwischen dem 
Netzwerk-Server und dem Client durch den 


Netzwerk-Server, und Speichem (1 33) des Ac- 
count-Namens und des PaGworts; 

als Reaktion auf die Anforderung zum Verbin- 
den mit, oder Zugreifen auf das erste Betriebs- 
etement, Bestimmen, daG das erste Betriebs- 
element vom Netzwerk-Server verwaltet wird, 
und Bestimmen, ob die Verbindung zum ersten 
Betriebselement (24) zur Verfugung steht; 

anschlieGend Senden (310) einer Anforderung 
von dem einen Client an den Netzwerk-Server 
zum Verbinden mit, oder Zugreifen auf ein 
zweites Betriebmittel (40, 44); und 

als Reaktion auf die nachfolgende Anforderung 
zum Verbinden mit, oder Zugreifen auf das 
zweite Betriebsmittel (40, 44) Bestimmen (140) 
durch den Netzwerk-Server, daB einer der 
Femrechner (30, 34) das zweite Betriebsmittel 
verwaltet, Senden (152) einer Anforderung 
vom Netzwerk-Server an den zweiten Fem- 
rechner auf Aufbauen einer Sitzung mit dem er- 
sten Femrechner, wobei diese Anforderung 
den gespeicherten Account-Namen und das 
gespeicherte PaGwort beinhaltet, und Senden 
einer Anforderung auf Verbindung mit, oder Zu- 
griff auf das zweite Betriebsmittel von dem 
Netzwerk-Server zu dem einen Femrechner. 

Verfahren gemaG Anspruch 1 , ferner enthaltend die 
folgenden aufeinanderfolgenden Schritte: 

Senden (340), von dem einen Client (11a-11z) 
an den Netzwerk-Server (14), einer Anforde- 
rung zum Verbinden mit, oder Zugreifen auf, ein 
drittes Betriebsmittel; 

Bestimmen durch den Netzwerk-Server, daB 
ein anderer der Femrechner das dritte Be- 
triebsmittel verwaltet; und 

Senden (130), durch den Netzwerk-Server zu 
dem anderen Femrechner, einer Anforderung 
auf Aufbau einer Sitzung, wobei die Sitzungs- 
aufbauanforderung den gespeicherten Ac- 
count-Namen und das gespeicherte PaBwort 
beinhaltet, sowie einer Anforderung auf An- 
schlieBen an, oder Zugriff auf, das dritte. Be- 
triebsmittel. 

Verfahren gemaG Anspruch 1 oder 2, ferner enthal- 
tend die folgenden Schritte: 

Uberprufen (324, 344) des in der Sitzungsauf- 
bauanforderung enthaltenen Account-Namens 
und des PaBworts durch den einen Femrech- 
ner, und 
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Aufbau (326, 334, 341) der durch den Netz- 
werk-Server angeforderten Sitzung durch den 
Fernrechner. 

4. Verfahren gemaB Anspruch 3, femer enthaltend die 
folgenden Schritte: 

Senden, von dem einen Client (1 1a-1 1 z) an den 
Netzwerk-Server (14), einer Anforderung zum 
Beenden der Sitzung; 

Bestimmen (202, 204) durch den Netzwerk- 
Server, daB der eine Fernrechner von der Sit- 
zung betroffen ist; 

Senden (352), durch den Netzwerk-Server an 
den einen Fernrechner, einer Anforderung zum 
Beenden der Sitzung, die vom Netzwerk-Ser- 
ver angefordert wurde; und 

Beenden (208) der Sitzung zwischen dem 
Netzwerk-Server und dem einen Client durch 
den Netzwerk-Server 

5. Verfahren gemaB Anspruch 1 Oder einem der An- 
spruche 2 bis 4, ferner enthaltend die folgenden 
Schritte: 

Nach der folgenden Anforderung, Stellen einer 
Anforderung durch ein weiteres Applikations- 
programm, das in dem einen Fernrechner ab- 
tauft, auf Zugriff auf das zweite Betriebsmittel 
(40, 44); und 

gemaB dem Applikationsprogramm Anforde- 
rung durch dieses andere Applikationspro- 
gramm, das durch diesen einen Fernrechner 
(30, 34) auf das andere Applikationsprogramm 
auf das zweite Betriebsmittel gibt Zugriff. 

6. Verfahren gemaB Anspruch 1 oder einem der An- 
spruche 2 bis 5, in dem die anschlieGende Verbin- 
dungs- oder Zug riff sanforde rung, die von dem ei- 
nen Client an den Netzwerk-Server gesendet wurde 
(140), das zweite Betriebsmittel mit Namen spezifi- 
ziert, jedoch nicht den einen Fernrechner oder den 
Standort des zweiten Betriebsmittels spezifiziert. 
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Senden (310), von einem der Clients an den 
Netzwerk-Server, einer Anforderung zum Auf- 
bau einer Sitzung, und einer Anforderung zum 
Verbinden mit, oder Zugreifen auf, ein erstes 
Betriebsmittel (40, 44), wobei diese Anforde- 
rungen vorzugsweise durch eine einzige Anfor- 
derung vorgesehen sind, und diese Sitzungs- 
aufbauAnforderung einen Account-Namen und 
ein PaBwort fur den betreffenden einen Client 
enthalt; 

als Reaktion auf die Sitzungsaufbauanforde- 
rung (1 23), Aufbau einer Sitzung mit dem Netz- 
werk-Server, und Speichern (133) des Ac- 
count-Namens und des PaBworts; 

als Reaktion auf die Anforderung zum Verbin- 
den oder Zugreifen, Bestimmen, daB einer der 
Fernrechner das erste Betriebselement (40, 
44) verwaltet (30, 34), Senden (152) einer An- 
forderung durch den Netzwerk-Server an den 
einen Fernrechner zum Aufbauen einer Sit- 
zung mit diesem einen Fernrechner, wobei die 
Anforderung den gespeicherten Account-Na- 
men und das gespeicherte PaBwort enthalt, 
und Senden einer Anforderung durch den Netz- 
werk-Server an den Fernrechner zum Verbin- 
den mit, oder Zugreifen auf das erste Betriebs- 
mittel; 

anschlieBend Senden (310) einer Anforderung 
von dem ersten Client an den Netzwerk-Server 
zum Verbinden mit, oder Zugreifen auf ein 
zweites Betriebsmittel; und 

als Reaktion auf die nachfolgende Anforde- 
rung, Bestimmen (140), daB der Netzwerk-Ser- 
ver das zweite Betriebsmittel verwaltet, und Be- 
stimmen, ob das zweite Betriebsmittel verfug- 
bar ist. 

Verfahren gemaB Anspruch 7, ferner beinhaltend 
den Schritt des Aufbaus der Sitzung mit dem einen 
Fernrechner durch den einen Fernrechner unter 
Uberprufung (324) des Account-Namens und des 
PaBworts als Reaktion auf die Sitzungsaufbauan- 
forderung (152) vom Netzwerk-Server. 


7. Ein Verfahren zum Verwalten des Zugriffs durch Cli- 
ents (11a-11z) in einem Netzwerk auf ein lokales 50 
Betriebsmittel (24), das von einem Netzwerk-Ser- 
ver (14) verwaltet wird, und ein oder mehrere Fern- 
betriebsmittel (40, 44), die von einem oder mehre- 
ren entsprechenden Fernrechnern (30, 34) verwal- 
tet werden, logisch und/oder physikalisch gekop- 55 
pelt an den Netzwerk-Server, wobei das Verfahren 
die folgenden Schritte umfaBt: 


9. Ein Netzwerk-Server (14) zum Verwalten des Zu- 
griffs durch Clients (11a-1 1z) in einem Netzwerk auf 
ein oder mehrere vom Netzwerk-Server verwaltete 
lokale Betriebsmittel (24), und ein oder mehrere 
Fernbetriebsmittel (40, 44), die von einem oder 
mehreren entsprechenden Fernrechnern (30, 34) 
verwaltet werden, logisch und/oder physikalisch 
gekoppelt an den Netzwerk-Server, wobei der Netz- 
werk-Server umfaBt: 
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Mittel (52) zum Empfangen, von einem der Cli- 
ents im Netzwerk, einer Anforderung zum Auf- 
bauen einer Sitzung, und einer Anforderung 
zum Verbinden mit, oder Zugreifen auf ein er- 
stes Betriebsmittel, in dem die Anforderungen s 
vorzugsweise durch eine einzige Anforderung 
gemacht warden, wobei die Sitzungsaufbauan- 
forderung einen Account-Namen und ein 
PaGwort fur den einen Client beinhaltet; 

10 

Mittel (53, 54) die auf die Sitzungsaufbauanfor- 
derung reagieren, zum Aufbauen einer Sitzung 
zwischen dem Netzwerk-Server und dem einen 
Client, und zum Speichern des Account-Na- 
mens und des PaBworts; '5 

Mittel (56), die auf die Anforderung zum Verbin- 
den mit, oder Zugreifen auf das erste Betriebs- 
mittel reagieren, zum Bestimmen, daG das er- 
ste Betriebsmittel vom Netzwerk-Server ver- 20 
waltet wird, und zum Bestimmen, ob die Ver- 
bindung fur das erste Betriebsmittel verfugbar 
ist; und 

Mittel (56, 60), die auf eine nachfolgende An- 25 
forderung von dem einen Client auf Verbindung 
mit, oder Zugriff zu einem zweiten Betriebsmit- 
tel reagieren, zum Bestimmen, daG einer der 
Fernrechner das zweite Betriebsmittel verwal- 
tet, Senden einer Anforderung an den einen 30 
Fernrechner zum Aufbau einer Sitzung mit dem 
einen Fernrechner, wobei die Anforderung den 
gespeicherten Account-Namen und das 
PaGwort enthalt, und Senden einer Anforde- 
rung an den einen Fernrechner zum Verbinden 35 
mit, oder Zugreifen auf das zweite Betriebsmit- 
tel. 


10. Netzwerk-Server gemaG Anspruch 9, in dem: 

40 

Das Bestimmungsmittel (56) auf eine andere 
Anforderung von dem einen Client auf Verbin- 
den mit, oder Zugreifen auf ein drittes Betriebs- 
mittel anspricht, zum Bestimmen, daG ein an- 
derer der Fernrechner das dritte Betriebsmittel *s 
verwaltet; und 

das Sendemittel (60) an den anderen Fern- 
rechner eine Anforderung zum Aufbau einer 
Sitzung sendet, diese Sitzungsaufbauanforde- so 
rung den gespeicherten Account-Namen und 
das PaGwort sowie eine Anforderung zum Ver- 
binden mit, oder Zugreifen auf das dritte Be- 
triebsmittel beinhaltet. 

55 

11. Netzwerk-Server gemaG Anspruch 9 oder 10, fer- 
ner enthaltend: 


30 

Mittel, die auf eine Anforderung von dem einen 
Client zum Beendigen der Sitzung ansprechen, 
zum Bestimmen, daG der eine Fernrechner von 
der Sitzung betroffen ist; 

Mittel (60) zum Senden einer Anforderung auf 
Beenden der vom Netzwerk-Server angefor- 
derten Sitzung an den einen Fernrechner; und 

Mittel zum Beenden der Sitzung zwischen dem 
Netzwerk-Server und dem einen Client. 

12. Netzwerk-Server gemaG Anspruch 9, 1 0 oder 11 , in 
dem die nachfolgende Verbindungs- oder Zu griffs - 
anforderung, die von dem einen Client an den Netz- 
werk-Server gesendet wurde, dieses zweite Be- 
triebsmittel mit Namen spezifiziert, aber nicht den 
einen Fernrechner oder einen Standort des von 
dem einen Fernrechner verwalteten Betriebsmittels 
spezifiziert. 

13. Ein Netzwerk-Server (14) zum Verwalten des Zu- 
griffs durch Clients (11 a-1 1 z) in einem Netzwerk auf 
ein lokales Betriebsmittel (24), das durch einen 
Netzwerk-Server verwaltet wird, und auf ein oder 
mehrere Fernbetriebsmittel (40, 44), die von einem 
oder mehreren entsprechenden Femrechnern (30, 
34) verwaltet werden, die an den Netzwerk-Server 
gekoppelt sind, wobei der Netzwerkserver umfaGt: 

Mittel (52, 53) zum Empfangen, von einem der 
Clients im Netzwerk, einer Anforderung zum 
Aufbau einer Sitzung und einer Anforderung 
zum Verbinden mit, oder Zugreifen auf, ein er- 
stes Betriebsmittel, wobei diese Sitzungsauf- 
bauAnforderung einen Account-Namen und 
ein PaGwort fur den betreffenden Client enthalt; 

Mittel (54, 60), die auf die Sitzungsaufbauan- 
forderung mit dem Aufbau einer Sitzung mit 
dem Netzwerk-Server und Speichern des Ac- 
count-Namens und des Pa 3 worts ansprechen; 

Mittel (56), die auf die Anforderung zum Verbin- 
den oder Zugreifen ansprechen, zum Bestim- 
men, daG einer der Fernrechner das erste Be- 
triebselement verwaltet, Senden einer Anfor- 
derung an den einen Fernrechner zum Aufbau 
einer Sitzung mit dem einen Fernrechner, wo- 
bei die Anforderung den gespeicherten Ac- 
count-Namen und das PaGwort enthalt, und 
Senden einer Anforderung an den Fernrechner 
zum Verbinden mit, oder Zugreifen auf das er- 
ste Betriebsmittel; und 

Mittel (56) die auf die nachfolgende Anforde- 
rung zum Verbinden mit, oder Zugreifen auf ein 
zweites Betriebsmittel ansprechen, zum Be- 
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stimmen, daG der Netzwerk-Server das zweite 
Betriebsmittel verwaltet, und Bestimmen, ob 
das zweite Betriebsmittel verfugbar ist. 


rung an den einen Fernrechner zum Verbinden 
mit, oderZugreifen auf das zweite Betriebsmit- 
tel; und 


14. Ein Rechnerprogrammprodukt zum Verwalten des 
Zugriffs durch Clients (11a-11z) in einem Netzwerk 
auf ein Oder mehrere lokale Betriebsmittel (24), die 
von einem Netzwerk-Server (14) verwaltet werden,, 
und ein Oder mehrere Fernbetriebsmitte! (40, 44), 
die von einem Oder mehreren entsprechenden 
Fernrechnern (30, 34) verwaltet werden, logisch 
und/oder physikalisch gekoppelt an den Netzwerk- 
Server, wobei das Rechnerprogrammprodukt um- 
faGt: 


5 in dem jedes dieser Programmanweisungsmit- 

tel durch den zugeordneten Rechnerprozessor 
ausfuhrbar ist. 

15. Ein Rechnerprogrammprodukt gemaG Anspruch 
10 14, in dem 

das dritte Programmanweisungsmittel auf eine 
weitere Anforderung von dem einen Client zum 
Verbinden mit, Oder Zugreifen auf ein drittes 
Betriebsmittel reagiert, durch Anweisen eines 
Rechnerprozessors zum Bestimmen, da 3 ein 
anderer dieser Fernrechner das dritte Betriebs- 
mittel verwaltet; und 

das vierte Programmanweisungsmittel einen 
Rechnerprozessor anweist, an dtesen anderen 
Fernrechner eine Anforderung zu senden, urn 
eine Sitzung aufzubauen, wobei diese Sit- 
zungsaufbauanforderung den gespeicherten 
Account-Namen und das PaGwort und eine An- 
forderung beinhaltet, sich mit dem dritten Be- 
triebsmittel zu verbinden oder darauf zuzugrei- 
fen. 

1 6. Ein Rechnerprogrammprodukt gemaG Anspruch 1 4 
oder 1 5, das ferner enthalt: 

funfte Programmanweisungsmittel, die auf 
dem Medium aufgezeichnet sind, zum Anwei- 
sen eines Rechnerprozessors, auf eine Anfor- 
derung des einen Client zum Beenden der Sit- 
zung zu reagieren, um zu bestimmen, daG der 
eine Fernrechner von der Sitzung betroffen ist; 

sechste Programmanweisungsmittel, die auf 
dem Medium aufgezeichnet sind, zum Anwei- 
sen eines Rechnerprozessors, an den einen 
Fernrechner eine Anforderung zum Beenden 
der von dem einen Netzwerk-Server angefor- 
derten Sitzung zu senden; und 

siebte Programmanweisungsmittel, die auf 
dem Medium aufgezeichnet sind, zum Anwei- 
sen eines Rechnerprozessors, die Sitzung zwi- 
schen dem Netzwerk-Server und dem einen 
Client zu beenden; und worin das funfte, sech- 
ste und siebte Programmanweisungsmittel 
durch den zugeordneten Rechnerprozessor 
ausfuhrbar ist. 

17. Ein Rechnerprogrammprodukt gemaG Anspruch 
14, 15 oder 16, in dem die anschlieGend von dem 
einen Client gesendete Verbindungs- oder Zugriffs- 


15 

ein Rechner-lesbares Medium; 

erste Programmanweisungsmittel, die auf dem 
Medium aufgezeichnet sind, zum Anweisen ei- 
nes Rechnerprozessors zum Empfangen einer 20 
Anforderung von einem der Clients oder vom 
Netzwerk zum Aufbau einer Sitzung, und einer 
Anforderung zum Verbinden mit, oder Zugrei- 
fen auf ein erstes Betriebsmittel, wobei die Sit- 
zungsaufbauanforderung einen Account-Na- 25 
men und ein PaGwort fur den einen Client ent- 
halt; 

zweite Programmanweisungsmittel, die auf 
dem Medium aufgezeichnet sind, zum Anwei- & 
sen eines Rechnerprozessors, auf die Sit- 
zungsaufbauanforderung zu reagieren mit dem 
Aufbau einer Sitzung zwischen dem Netzwerk- 
Server und dem Client, und Abspeichem des 
Account-Namens und des PaGworts; 35 

dritte Programmanweisungsmittel, die auf dem 
Medium aufgezeichnet sind, zum Anweisen ei- 
nes Rechnerprozessors, auf die Anforderung 
zum Verbinden mit, oder zum Zugreifen auf das 40 
erste Betriebsmittel, zu reagieren durch Be- 
stimmen, daG das erste Betriebsmittel vom 
Netzwerk-Server verwaltet wird, und Bestim- 
men, ob die Verbindung zum ersten Betriebs- 
mittel verfugbar ist; 45 

vierte Programmanweisungsmittel, die auf dem 
Medium aufgezeichnet sind, zum Anweisen ei- 
nes Rechnerprozessors, auf die Anforderung 
von dem einen Client zum Verbinden mit, oder so 
Zugreifen auf das zweite Betriebsmittel, zu rea- 
gieren durch Bestimmen, daG einer der Fern- 
rechner das zweite Betriebsmittel verwaltet, 
durch Senden einer Anforderung an den Fern- 
rechner zum Aufbauen einer Sitzung mit dem ss 
einen Fernrechner, wobei die Anforderung den 
gespeicherten Account-Namen und das 
PaGwort beinhaltet, und Senden einer Anforde- 
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anforderung das zweite Betriebsmittel mit dem Na- 
men spezifiziert, jedoch nichtden Fernrechner oder 
eine Adresse des Betriebsmrttels spezifiziert, das 
der eine Fernrechner verwaltet. 

5 

18. Ein Rechnerprogrammprodukt zum Verwalten des 
Zugriffs durch Clients in einem Netzwerk auf ein lo- 
kales Betriebsmittel, das vom Netzwerk-Server ver- 
waltet wird, und ein oder mehrere Fembetriebsmit- 
tel, die von einem oder mehreren entsprechenden 10 
Fernrechner verwaltet werden, wobeidas Rechner- 
produkt enthalt: 

erste Programmanweisungsmittel, die auf dem 
Medium aufgezeichnet sind, zum Anweisen ei- is 
nes Rechnerprozessors zum Empfangen einer 
Anforderung von einem dieser Clients auf dem 
Netzwerk zum Aufbau einer Sitzung, und einer 
Anforderung zum Verbinden mit, oder Zugrei- 
f en auf ein erstes Betriebsmittel, wobei die Sit- 20 
zungsaufbauanforderung einen Account-Na- 
men und ein PaBwort fur diesen einen Clienten 
beinhaltet; 

zweite Programmanweisungsmittel, die auf 2s 
dem Medium aufgezeichnet sind, zum Anwei- 
sen eines Rechnerprozessors, auf die Sit- 
zungsaufbauanforderung durch Aufbau einer 
Sitzung mit dem Netzwerk-Server und Spei- 
chern des Account- Nam ens und des PaGworts 30 
zu reagieren; 

dritte Programmanweisungsmittel, die auf dem 
Medium aufgezeichnet sind, zum Anweisen ei- 
nes Rechnerprozessors, auf die Verbindungs- 35 
oder Zugriffsaufforderung zu reagieren durch 
Bestimmen, daG einer der Fernrechner das er- 
ste Betriebsmittel verwaltet, durch Senden ei- 
ner Anforderung an den einen Fernrechner, ei- 
ne Sitzung mit dem einen Fernrechner aufzu- *o 
bauen, wobei die Anforderung einen abgespei- 
cherten Account-Namen und ein PaGwort be- 
inhaltet, und Senden einer Anforderung an den 
Fernrechner, um mit dem ersten Betriebsmittel 
verbunden zu werden oder darauf Zugriff zu 45 
nehmen; und 

vierte Programmanweisungsmittel, die auf dem 
Medium aufgezeichnet sind, zum Anweisen ei- 
nes Rechnerprozessors, auf eine nachfolgen- so 
de Anforderung zum Verbinden mit, oder Zu- 
griff auf ein zweites Betriebsmittel zu nehmen, 
zu reagieren durch Feststellung, daG der Netz- 
werk-Server das zweite Betriebsmittel verwal- 
tet, und Bestimmen, ob das zweite Betriebsmit- 55 
tel verfugbar ist; und in dem jedes der Pro- 
grammanweisungsmittel durch den beigeord- 
neten Rechnerprozessor ausfuhrbar ist. 


Revendlcations 

1. Precede destine a gerer des acces par des clients 
(11 a a 11 z) dans un reseau a une ou plusieurs res- 
sources locales (24) gerees par un serveur de re- 
seau (14) et uneou plusieurs ressources a distance 
(40, 44) gerees par un ou plusieurs ordinateurs a 
distance respectifs (30, 34) logiquement et/ou phy- 
siquement relies au serveur de reseau, ledit prece- 
de comprenant les etapes consistant a : 

envoyer (310) depuis Tun desdits clients audit 
serveur de reseau, une demande pour etablir 
une session et une demande pour se connecter 
ou acceder a une premiere ressource (24), 
dans lequel lesdites demandes sont de prefe- 
rence fournies grace a une demande unique, 
ladite demande d'etablissement de session 
comprenant un nom de compte et un mot de 
passe pour ledit un client, 

en reponse a la demande d'etablissement de 
session (123), etablir par ledit serveur de re- 
seau une session entre ledit serveur de reseau 
et ledit client, et memoriser (133) lesdits nom 
de compte et mot de passe, 

en reponse a la demande pour se connecter ou 
acceder a ladite premiere ressource, determi- 
ner que ladite premiere ressource est geree par 
ledit serveur de reseau, et determiner si ladite 
connexion est disponible pour ladite premiere 
ressource (24), 

ensuite, envoyer (310) depuis ledit un client 
vers ledit serveur de reseau, une demande 
pour se connecter ou acceder a une seconde 
ressource (40, 44), et 

en reponse a ladite demande suivante pour se 
connecter ou acceder a ladite seconde res- 
source (40, 44), determiner (140) par ledit ser- 
veur de reseau que Tun desdits ordinateurs a 
distance (30, 34) gere ladite seconde ressour- 
ce, envoyer (152) une demande par ledit ser- 
veur de reseau vers ledit un ordinateur a dis- 
tance afin d'etablir une session avec ledit un or- 
dinateur a distance, ladite demande compre- 
nant lesdits nom de compte et mot de passe 
memorises, et envoyer une demande par ledit 
serveur de reseau audit un ordinateur a distan- 
ce afin de se connecter ou d'acceder a ladite 
seconde ressource nommee. 

2. Precede selon la revendication 1, comprenant en 
outre les etapes suivantes consistant a : 

envoyer (340) depuis ledit un client (11a a 11z) 
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audit serveur de reseau (14) une demande 
pour se connecter ou acceder a une troisieme 
ressource, 

determiner par I edit serveur de r6seau qu'un s 
autre desdits ordinate urs a distance gere ladite 
troisieme ressource, et 

envoyer (1 30) par ledit serveur de reseau audit 
autre ordinateur a distance une demande pour 10 
6tablir une session, Eadite demande d'dtablis- 
sement de session comprenant lesdits nom de 
compte et mot de passe memorises, et une de- 
mande pour se connecter ou acceder a ladite 
troisieme ressource. *5 

3. Proc§d§ selon la revendication 1 ou 2, comprenant 
en outre les Stapes consistant a : 

valider (324, 344) par ledit un ordinateur a dis- 20 
tance lesdits nom de compte et mot de passe 
inclus dans ladite demande d'etablissement de 
session, et 

dtablir (326, 334, 341 ) par ledit un ordinateur a 25 
distance ladite session demanded par ledit ser- 
veur de reseau. 

4. ProcedS selon la revendication 3 comprenant en 
outre les Stapes consistant a : 30 

envoyer depuis ledit un client (11a a 11 z) audit 
serveur de reseau (14) une demande pour met- 
tre fin a ladite session, 

35 

determiner (202, 204) par ledit serveur de re- 
seau que ledit un ordinateur a distance est im- 
plique dans ladite session, 

envoyer (352) par ledit serveur de reseau audit *o 
un ordinateur a distance une demande pour 
mettre fin a ladite session demanded par ledit 
serveur de reseau, et 

mettre fin (208) par ledit serveur de reseau a la 
session entre ledit serveur de reseau et ledit un 
client. 

5. Precede" selon la revendication 1 ou t'une des re- 
vendications 2 a 4, comprenant en outre les stapes so 
consistant a : 

apres ladite demande suivante, effectuer une 
demande par un autre programme duplica- 
tion s'exScutant a I'intSrieur dud it un ordinateur ss 
a distance en vue d'acceder a ladite seconde 
ressource (40, 44), et 


a la suite de ladite demande de programme 
duplication par ledit autre programme dupli- 
cation, realiser un acces par ledit un ordinateur 
a distance (30, 34) audit autre programme d'ap- 
plication sur ladite seconde ressource. 

6. Precede selon la revendication 1 ou Tune des re- 
vendications 2 a 5, dans lequel la demande de con- 
nexion ou d'acces suivante envoyee (1 40) par ledit 
un client audit serveur de reseau specifie ladite se- 
conde ressource par un nom, mais ne specifie pas 
ledit un ordinateur a distance ni ('emplacement de 
ladite seconde ressource. 

7. Precede destine" a gSrer des acces par des clients 
(11a a 11 z) dans un reseau a une ressource locale 
(24) g£r£e par un serveur de reseau (1 4) et une ou 
plusieurs ressources a distance (40, 440) g6rees 
par un ou plusieurs ordinateurs a distance respec- 
tifs (30, 34) logiquement et/ou physiquement relics 
au serveur de reseau, ledit procSde* comprenant les 
etapes consistant a : 

envoyer (310) depuis Tun desdits clients audit 
serveur de r6seau une demande en vue d'Sta- 
bfir une session et une demande pour se con- 
necter ou accSder a une premiere ressource 
(40, 44), dans lequel lesdites demandes sont 
de presence r6alis6es grace a une demande 
unique, ladite demande d'etablissement de 
session comprenant un nom de compte et un 
mot de passe pour ledit un client, 

en reponse a la demande d'etablissement de 
session (123), Stablir par ledit serveur de re- 
seau une session avec ledit serveur de reseau, 
et mSmoriser (1 33) lesdits nom de compte et 
mot de passe, 

en reponse a la demande de connexion ou 
d'acces, determiner que Tun desdits ordina- 
teurs a distance gere (30, 34) ladite premiere 
ressource (40, 44), envoyer (152) une deman- 
de par ledit serveur de reseau audit un ordina- 
teur a distance afin d'Stablir une session avec 
ledit un ordinateur a distance, ladite demande 
comprenant lesdits nom de compte et mot de 
passe memorises, et envoyer une demande 
par ledit serveur de reseau audit ordinateur a 
distance pour se connecter ou acceder a ladite 
premiere ressource, 

ensuite, envoyer (310) depuis ledit un client 
audit serveur de reseau une demande pour se 
connecter ou acceder a une seconde ressour- 
ce, et 

en rdponse a ladite demande suivante, deter- 
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miner (1 40) que led it serveur de reseau gere 
I ad it e seconde ressource, et determiner si ladi- 
te seconde ressource est disponible. 

8. Proc6d6 selon la revendication 7, comprenant en s 
outre I'etape consistanta etablir ladite session avec 
(edit un ordinateur a distance en faisant valider par 
ledrt un ordinateur a distance (324) lesdits nom de 
compte et mot de passe, en reponse a ladite de- 
mande d'etablissement de session (1 52) provenant 10 
dudit serveur de reseau. 

9. Serveur de reseau (14) destine a gerer des acces 
par des clients (11a a 1 1 z) dans un reseau a une 

ou plusieurs ressources locales (24) g6rees par le- ^ 
dit serveur de reseau et une ou plusieurs ressour- 
ces a distance (40, 44) g£rees par un ou plusieurs 
ordinateurs a distance respectifs (30, 34) logique- 
ment et/ou physiquement relies au serveur de re- 
seau, ledit serveur de reseau comprenant : 20 

un moyen (52) destine a recevoir de Tun desdits 
clients sur ledit reseau une demands pour eta- 
blir une session et une demande pour se con- 
necter ou acceder a une premiere ressource, 25 
dans lequel lesdites demandes sont de prefe- 
rence realisees par une demande unique, la 
demande d'etablissement de session compre- 
nant un nom de compte et un mot de passe 
pour ledit un client, so 


lequel : 

le moyen de determination (56) repond a une 
autre demande provenant dudit un client pour 
se connecter ou pour acceder a une troisieme 
ressource afin de determiner qu'un autre des- 
dits ordinateurs a distance gere ladite troisieme 
ressource, et 

le moyen d'envoi (60) envoie audit autre ordi- 
nateur a distance une demande pour etablir 
une session, ladite demande d'etablissement 
de session comprenant lesdits nom de compte 
et mot de passe memorises, et une demande 
pour se connecter ou pour acceder a ladite troi- 
sieme ressource. 

11. Serveur de reseau selon la revendication 9 ou 10, 
comprenant en outre : 

un moyen, repondant a une demande prove- 
nant dudit un client pour mettre fin a ladite ses- 
sion, en vue de determiner que ledit un ordina- 
teur a distance est implique dans ladite ses- 
sion, 

un moyen (60) destine a envoyer audit un ordi- 
nateur a distance une demande pour mettre fin 
a ladite session demanded par ledit serveur de 
reseau, et 


un moyen (53, 54) repondant a la demande 
d'etablissement de session, en vue d'etablir 
une session entre ledit serveur de reseau et le- 
dit un client, et memoriser lesdits nom de comp- 35 
te et mot de passe, 

un moyen (56), repondant a la demande pour 
se connecter ou acceder a ladite premiere res- 
source, afin de determiner que ladite premiere 40 
ressource est g6r6e par ledrt serveur de re- 
seau, et determiner si ladite connexion est dis- 
ponible a ladite premiere ressource, et 

un moyen (56, 60) repondant a une demande 
suivante provenant dudit un client pour se con- 
necter ou pour acceder a une seconde ressour- 
ce, afin de determiner que Tun desdits ordina- 
teurs a distance gere ladite seconde ressource, 
envoyer une demande audit un ordinateur a 50 
distance afin d'etablir une session avec ledit un 
ordinateur a distance, ladite demande compre- 
nant lesdits nom de compte et mot de passe 
memorises, et envoyer une demande audit un 
ordinateur a distance pour se connecter ou ac- 5$ 
ceder a ladite seconde ressource. 

10. Serveur de reseau selon la revendication 9, dans 


un moyen destine a mettre fin a la session entre 
ledit serveur de reseau et ledit un client. 

12. Serveur de reseau selon la revendication 9, 10 ou 
11 , dans lequel la demande de connexion ou d'ac- 
c6s suivante 6mise par ledit un client vers ledit ser- 
veur de reseau specifie ladite seconde ressource 
par un nom, mais ne specifie pas ledit un ordinateur 
a distance ni un emplacement de la ressource ge- 
ree audit un ordinateur a distance. 

13. Serveur de reseau (14) destine a gerer un acces 
par des clients (11a a 11z) dans un reseau a une 
ressource locale (24) ge>6e par le serveur de re- 
seau et une ou plusieurs ressources a distance (40, 
44) gerees par un ou plusieurs ordinateurs a distan- 
ce respectifs (30, 34) relies au serveur de reseau, 
ledit serveur de reseau comprenant : 

un moyen (52, 53) destine a recevoir de I'un 
desdits clients sur ledit reseau, une demande 
en vue d'etablir une session et une demande 
pour se connecter ou pour acc6der a une pre- 
miere ressource, la demande d'etablissement 
de session comprenant un nom de compte et 
un mot de passe pour ledit un client, 
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un moyen (54, 60) repondant a la demande 
d'etablissement de session, afin d'etablir une 
session avec ledit serveur de r6seau, et m6mo- 
riser lesdits nom de compte et mot de passe, 

5 

un moyen (56), repondant a la demande de 
connexion ou d'acces, afin de determiner que 
Tun desdits ordinateurs a distance gere ladite 
premiere ressource, envoy er une demande 
audit un ordinateur a distance afin d'etablir une 10 
session avec ledit un ordinateur k distance, la- 
dite demande comprenant lesdits nom de 
compte et mot de passe memorises, et envoyer 
une demande audit ordinateur a distance pour 
se connecter ou pour acceder a ladite premiere is 
ressource, et 

un moyen (56), repondant k une demande sui- 
vante pour se connecter ou acceder k une se- 
conde ressource, afin de determiner que ledit 20 
serveur de reseau gere ladite seconde ressour- 
ce, et determiner si ladite seconde ressource 
est disponible. 

1 4. Produit de programme informatique destine a g6rer 2$ 
des acces par des clients (11a a 11z) dans un r6- 
seau a une ou plusieurs ressources locales (24) gd- 
r6es par le serveur de r6seau (14) et une ou plu- 
sieurs ressources a distance (40, 44) g6r6es par un 
ou plusieurs ordinateurs a distance respectifs (30, so 
34) logiquement et/ou physiquement relies au ser- 
veur de reseau, ledit produit de programme infor- 
matique comprenant : 

un support lisible par un ordinateur, 35 

des premiers moyens destruction de program- 
me, enregistres sur ledit support, en vue de 
donner pour instruction a un processeur d'ordi- 
nateur de recevoir de Tun dudit client ou dudit 40 
reseau une demande en vue d'etablir une ses- 
sion etunedemande pourse connecterou pour 
acc6der k une premiere ressource, la demande 
d'etablissement de session comprenant un 
nom de compte et un mot de passe pour ledit 
un client, 

des seconds moyens destruction de program- 
me, enregistres sur ledit support, en vue de 
donner pour instruction a un processeur d'ordi- so 
nateur de repondre a la demande d'etablisse- 
ment de session, en etablissant une session 
entre ledit serveur de reseau et ledit client, et 
memoriser lesdits nom de compte et mot de 
passe, 55 

des troisiemes moyens destruction de pro- 
gramme, enregistres sur ledit support, en vue 


40 

de donner pour instruction a un processeur 
d'ordinateur de repondre a la demande pour se 
connecter ou pour accede r a ladite premiere 
ressource, en determinant que ladite premiere 
ressource est geree par ledit serveur de re- 
seau, et en determinant si ladite connexion est 
disponible a ladite premiere ressource, et 

des quatriemes moyens destruction de pro- 
gramme, enregistres sur ledit support, en vue 
de donner pour instruction a un processeur 
d'ordinateur de repondre a une demande sui- 
vanteprovenant dudit un client pourse connec- 
terou acceder a une seconde ressource, en de- 
terminant que Tun desdits ordinateurs a distan- 
ce gere ladite seconde ressource, envoyer une 
demande audit un ordinateur a distance pour 
etablir une session avec ledit un ordinateur a 
distance, ladite demande comprenant lesdits 
nom de compte et mot de passe memorises, et 
envoyer une demande audit un ordinateur a 
distance pour se connecter ou acceder k ladite 
seconde ressource, et 

dans lequel chacun desdits moyens d'instruc- 
tion de programme est executable par le pro- 
cesseur d'ordinateur associe. 

15. Produit de programme informatique selon la reven- 
dication 14, dans lequel 

les troisiemes moyens destruction de pro- 
gramme repondent a une autre demande pro- 
venant dudit un client pour se connecter ou ac- 
ceder a une troisi6me ressource en donnant 
pour instruction a un processeur d'ordinateur 
de determiner qu'un autre desdits ordinateurs 
a distance gere ladite troisieme ressource, et 

les quatriemes moyens destruction de pro- 
gramme donnent pour instruction k un proces- 
seur d'ordinateur d'envoyer audit autre ordina- 
teur a distance une demande en vue d'etablir 
une session, ladite demande d'etablissement 
de session comprenant lesdits nom de compte 
et mot de passe memorises, et une demande 
pour se connecter ou acceder k ladite troisieme 
ressource. 

16. Produit de programme informatique selon la reven- 
dication 14 ou 15, comprenant en outre : 

des cinquiemes moyens destruction de pro- 
gramme, enregistres sur ledit support, en vue 
de donner pour instruction a un processeur 
d'ordinateur de repondre k une demande pro- 
venant dudit un client pour mettre fin a ladite 
session, afin de determiner que ledit un ordina- 
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42 


teur a distance est implique dans I ad it e ses- 
sion, 

des sixiemes moyens d'instruction de program- 
me, enregistres sur ledit support, afin de don- 5 
ner pour instruction a un processeur d'ordina- 
teur d'envoyer audit un ordinateur a distance 
une demande pour mettre fin a ladite session 
demandee par ledit serveur de reseau, et 

JO 

des septiemes moyens d'instruction de pro- 
gramme, enregistres sur ledit support, en vue 
de donner pour instruction a un processeur 
d'ordinateur de mettre fin a la session entre le- 
dit serveur de reseau et ledit un client, et dans '5 
lequel ledit cinquieme, sixieme et septieme 
moyens d'instruction de programme sont exe- 
cutables par le processeur d'ordinateur asso- 
cie. 

20 

17. Produit de programme informatique selon la reven- 
dication 14, 15 ou 16, dans lequel la demande de 
connexion ou d'acces suivante emise par ledit un 
client specifie ladite seconde ressource par un nom, 
mais ne specifie pas (edit un ordinateur a distance 25 
ni une adresse de la ressource geree audit un ordi- 
nateur a distance. 

1 8. Produit de programme informatique destine a gerer 

un acces par des clients dans un reseau a un res- so 
source locale ger£e par le serveur de reseau et une 
ou plusieurs ressources a distance gerees par un 
ou plusieurs ordinateurs a distance respectifs relies 
au serveur de reseau, ledit produit de programme 
informatique comprenant : 35 

des premiers moyens d'instruction de program- 
me, enregistres sur ledit support, en vue de 
donner pour instruction a un processeur d'ordi- 
nateur de recevoir de Tun desdits clients sur le- 40 
dit reseau une demande pour etablir une ses- 
sion et une demande pour se connecter ou ac- 
ceder a une premiere ressource, ta demande 
d'elablissement de session comprenant un 
nom de compte et un mot de passe pour ledit & 
un client, 

des seconds moyens d'instruction de program- 
me, enregistres sur ledit support, en vue de 
donner pour instruction a un processeur d'ordi- so 
nateur de repondre a la demande d'etablisse- 
ment de session en dtablissant une session 
avec ledit serveur de reseau, et en memorisant 
lesdits nom de compte et mot de passe, 

55 

des troisiemes moyens d'instruction de pro- 
gramme, enregistres sur ledit support, en vue 
de donner pour instruction a un processeur 


d'ordinateur de repondre a la demande de con- 
nexion ou d'acces en determinant que I'un des- 
dits ordinateurs a distance gere ladite premiere 
ressource, envoyer une demande audit un or- 
dinateur a distance pour etablir une session 
avec ledit un ordinateur a distance, ladite de- 
mande comprenant lesdits nom de compte et 
mot de passe memorises, et envoyer une de- 
mande audit ordinateur a distance pour se con- 
necter ou acceder a ladite premiere ressource, 
et 

des quatriemes moyens d'instruction de pro- 
gramme, enregistres sur ledit support, en vue 
de donner pour instruction a un processeur 
d'ordinateur de repondre a une demande sui- 
vante pour se connecter ou acceder a une se- 
conde ressource en determinant que ledit ser- 
veur de reseau gere ladite seconde ressource, 
et determiner si ladite seconde ressource est 
disponible, et dans lequel 

chacun desdits moyens d'instruction de pro- 
gramme est executable par le processeur d'or- 
dinateur associe. 
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